BBS Toolkit

home *** CD-ROM | disk | FTP | other *** search

/ BBS Toolkit / BBS Toolkit.iso / doors_2 / rnet107u.zip / RNET.DOC < prev next >

Wrap

Text File | 1991-01-03 | 72KB | 1,426 lines

RNET.DOC Page 1 ╓──────┐ ╓────┐╓─┐ ╓─────┐ ╓─────┐ ║ ╒══╗ │ ║ ╒╗ │║ │ ║ ╒═══╛ ╚═╗ ╒═╛ Version: 1.07 ║ └──╜ │ ║ │║ │║ │ ║ └─┐ ║ │ Release: Jan 03 1991 ║ ╒═╗ ╒╛ ║ │║ │║ │ ║ ╒═╛ ║ │ ║ │ ║ └┐ ║ │║ └╜ │ ║ └───┐ ║ │ Copyright 1989,1990 Robert Vostreys ╚═╛ ╚══╛ ╚═╛╚════╛ ╚═════╛ ╚═╛ All Rights Reserved PCBoard 14.x EchoConference driver for "QWK" packet based EchoNetworks. _____________________________Naming Conventions____________________________ RNet is distributed using the filenaming convention of: RNETvvvx.zzz. VVV refers to the version, such as '106' for version 1.06, '200' for version 2.00. The X refers to a letter code specifying alpha, beta, registered, and shareware release versions. Alpha and beta versions of RNet begin at 'A' and continue no further than 'P'. The registered release version is distributed as RNETvvvR.zzz, the shareware release version is distributed as RNETvvvU.zzz ('U' for unregistered). The final ZZZ refers to the compression utility extension, which will usually be .ARC or .ZIP or whatever. When referring to this distribution file in the documentation, it will usually be referred to as "ZIP file." _____________________________Distribution File_____________________________ The following files should be present within the distribution ZIP file: RNET.EXE Main executable program RNET.DOC The documentation you are currently reading (RTFM!) RNET_REF.DOC Quick reference for RNet configuration and operation REGISTER.DOC Shareware registration form and information CHANGES.vvv Changes from version to version (history files) ECHOS.DOC Description and information about EchoConferencing MESSAGES.DOC Listing of errors which are not otherwise explained RNETCONF.DOC Information on PCBCONF and PROCONF interfacing PCBCONF.EXE Interface utility for PCBoard CNAMES conferences PROCONF.EXE Interface utility for ProDoor CONFINFO conferences SAMPLE1.CFG Sample (verbose) configuration file with comments SAMPLE2.CFG Sample (brief) HOST_ID.CFG configuration file MAILRUN.BAT Example BAT for making a host mail transfer MAILRUN.SLT Example Telix SALT for host mail transfers PCBLOGIN.SLT Example Telix SALT to login to host and open maildoor LOWMEM.BAT Example BAT for using external compression RNET.DOC Page 2 Alpha/Beta versions usually do not include the .DOC files but instead include the CHANGES.vvv file for that version. Please be sure to read this file if you are working with an alpha or beta version of RNet! _____________________________Distribution Rules____________________________ Sysops MAY place 'ZIP Comments' on the RNet distribution ZIP file if they normally do such with all their download files. Sysops MAY NOT place additional files (such as 'README.1ST' or 'BBS_AD') within the distribution ZIP file nor may they use the PKZIP -AV verification stamp. Distribution of the alpha, beta, and registered versions is restricted to those systems with specific permission to distribute such. Do not distribute any version of RNet except the unregistered (RNETxxxU) version! RNET.DOC Page 3 ___________________________Contacting the Author___________________________ Problems, questions, and suggestions should be directed to Robert Vostreys: Modem: Faster-Than-Light BBS Node1: 404-292-8761 [300 to 2400, non-MNP] Node2: 404-299-3930 [300 to 14400 USR HST] US Mail: Robert Vostreys, FTL Sysop Post Office Box 2315 Stone Mountain, GA 30086-2315 EchoMail: ILink: Sysops, MM-RNet, or Admin EchoConferences. RIME: Sysops or Admin EchoConferences (route ->FTL). Atlanta: AtlSysops or NetLANTA EchoConferences. _________________________________Shareware_________________________________ Since you have likely read statements under the heading "Shareware" often, I'll not bother going into the idea again. Simply be aware that RNet is shareware ($20US suggested), the registered version has some additional features, and that the file REGISTER.DOC contains the shareware registration form and information. Any and all registered users may download and operate any later 1.xx registered and beta versions of RNet as desired. The registered and beta versions are always available from these BBS's (all of which support Dual Standard or 14400 USR HST connects): Faster-Than-Light 404-292-8761 / 299-3930 The Right Place<tm> 404-276-2607 / 476-0847 Sleepy Hollow 213-859-9334 Higher Powered BBS 408-737-9447 Solutions BBS 804-471-2874 / 471-3487 RNET.DOC Page 4 __________________________________Overview_________________________________ RNet is a utility to transfer messages from one BBS to another using the QWK packet format. The transfer/sharing of messages between BBS's is commonly referred to as "EchoMail", "NetMail", or "EchoConferencing." For more information on echo network design and the terms used within this document, see ECHOS.DOC. RNet will insert QWK packet messages into your PCBoard 14.x messagebases and export new messages in a REP packet for insertion into a host system's messagebases. If you are familiar with the operation of EZ-Reader, Deluxe, AmigaReader or similar QWK packet offline readers, most of the terms and ideas used here will be familiar. The actual transfer of QWK/REP packets is left up to you and your choice of communications programs. Canned scripts and programs such as RoboComm will work well to automate mail transfers. A working example of a Telix SALT script (MAILRUN.SLT) is included for your use and information. Usually, RNet is used in a system "event" to process incoming and outgoing mail to a network host during the night (when long distance carrier rates are lower). RNet is designed to be extremely dependable, which may substitute safety at the expense of speed. While RNet is for use with PCBoard 14.x (or ProDoor/ProBBS), your host need not be running a PCBoard system. TomCat! is an example of a WildCat! door and MarkMail is an example of a PCBoard/ProDoor door. RNet is designed to be very verbose (both on-screen, error/warning reports, report generation options, callerlog reporting in two formats), and even shows on the Node Chat display when running. If something goes wrong or if a condition exists(ed) that warrants attention, a log entry will be made to ERROR.LOG with any other information you might need. There are a variety of reports and logs that can be produced as desired. RNET.DOC Page 5 ________________________________Feature List_______________________________ Support for most (all?) QWK packet mail doors that support NetStatus. Limited to 32,765 conferences _per_ configuration / host QWK packet. Limited to 32,765 conferences _per_ CNAMES or CONFINFO file (or create your own conference location file (RNETCONF) using a text editor for complete control.) You may have an unlimited number of hosts and configuration files. Complete multi-node concurrent access to local conferences supported -- you will never lose a message due to concurrent messagebase insertions, even if running RNet on several nodes concurrently importing into the same messagebases. Includes support for PCBoard 14.5 DOS 3.1 record locking. Support for PCBoard 14.x CNAMES (39 and 65534 conference versions) and ProDoor CONFINFO (255 and 2040 conference versions). Always sends Host Sysop their private (R/O) messages. Always imports private messages addressed to the Local Sysop. This allows you and your host to have a private conversation even in public-transfer-only conferences/networks. Support for multiple hosts (using the same messagebases) with or without cross echoing as desired. This is useful for gateway connections between two or more networks. Private (R/O) messages can be passed or limited on a global or conference- by-conference basis. You may choose to honor or ignore the PCBoard 14.x "ECHO" flag. Completely definable tagline. The registered version of RNet allows you to define the ENTIRE tagline (no software "id" involved -- what you define is what you get!) A separate text-editable pointer file is maintained for each host. Pointer files are automatically backed up when a new REP packet is created. Special "Network Sysop" functions are supported to allow the network administration to route very important messages to your MAIN BOARD if needing such attention. Writes logs and pointer files to the drive/directory where the configuration file is found. This allows you to execute RNet from wherever is convenient for your particular system configuration. Local display (processing screen) supports 25/43/50/60 line modes. Conference usage analysis reports showing activity in network conferences and percentage of traffic generated locally. Message filtering: RNet will expand TABs, strip unneeded spaces, remove bells/^S/^X, pack blank lines from taglines, and even decrypt John Hancock encrypted taglines if desired. RNET.DOC Page 6 Handles and reports bad or corrupted PCBoard messagebases and NDX files. Automatically builds a pointer file for each host. If you add a conference, you need not reset a pointer as RNet will assume you want to start at the high message number. Intelligent pointer handling. If a pointer is set to a message lower than the lowest message, RNet will reset the pointer to the low message. If a pointer is set above the high message, RNet will reset the pointer to the high message. You may safely change pointers to any value if needed (such as to force export of an entire messagebase for a crashed host or to make a backup). Warns you if you receive a conference in a QWK packet that you have not yet configured on your end. Special commandline operations to force RNet to import/export only a single specific conference or to "continue" importing in a QWK packet that stopped for some reason (such as disk full). No need to reprocess the entire packet insertion! Automatic appending of messages to the REP packet if a REP packet is found present when running an export. This is can be enabled and is suggested since it allows you to continue "building" on a REP even if your host is busy or down. TCANNING of messages to/from specific users. You can even TCAN messages that are "from" a user, but not those "to" that user and/or vice-versa. Users (and the Sysop for that matter) can "watch" RNet's operation on the Node Chat display in PCBoard. RNet looks like a normal "user". The "City" display is used to relay what RNet is specifically doing at that time. Option to delete QWK packets after successful import automatically. If an import is unsuccessful, RNet will leave the QWK packet there for your further investigation. Networks which support NETNEWS type conferences have a much easier time with RNet. RNet can automatically copy messages in special conferences (such as Administration level conferences) into a NetNews conference. Also, special messages (from a specific name/person, with a specific keyword/subject) can be posted in the NetNews and transferred out along the Administration level conferences. This keeps ALL chitchat out of NetNews style conferences. Automatic processing of multiple QWK packets (such as *.QWK, *.QW0,.. up to *.QW9). Useful if using a "pre-built" packet door such as QMail 4.xx which may result in your downloading multiple packets for RNet to process. Automatic import speed determination. RNet watches what other users are doing via the USERNET.DAT file to decide how safe it is to import messages quickly or safely. If someone on another node (even another RNet) is entering a message, RNet will flush the DOS directory structure after each message for safety in importing messages. Otherwise, RNet flushes after each conference is completed. Safety FIRST! RNET.DOC Page 7 _________________________________NetStatus_________________________________ NetStatus refers to your having the "permission" of a host system to echo a messagebase (or bases). You might have NetStatus on perhaps only one or two conferences of that particular host's conferences -- that is up to the discretion of your host. The host Sysop _must_ enable NetStatus for you before you can transfer any messages back and forth! Usually this is done with your being accepted into an echo network such as ILink or SmartNet, or it may simply be that you and another sysop wish to echo (transfer) a debate conference between your boards. Your host must enable NetStatus for your user record within the maildoor you will be using for echoing messages. If you do not have NetStatus, RNet will write a log entry to ERROR.LOG and skip the conference(s) in question. If you are setting up for echomail and do not yet have NetStatus on the host system, you will not be permitted to import messages from the host system. Exporting of messages with RNet will correctly create a REP file, but they will not be accepted on the host without NetStatus enabled. _________________________________MailDoors_________________________________ For RNet to process messages to/from a host system your host must support a QWK packet format mail door. This is where you will download QWK packets (which contain new messages coming from the host/upper network) and upload your REP packets (containing messages from your system/lower network). Each BBS running a mail door is assigned a HOST_ID. If your host was, for example, "Faster-Than-Light BBS", the assigned HOST_ID might be "FTL". Ask your host what the HOST_ID is if not obvious from within the mail door. When you request new messages from your host's mail door, a HOST_ID.QWK packet will be constructed with new messages. Using the above example, the packet would be called FTL.QWK. When RNet collects new messages from your system to be sent up to the host, it will create a HOST_ID.REP packet, such as FTL.REP. Different mail doors support different maximum conferences for echomail. These limitations are for the number of conferences the HOST can support, not how many conferences you might wish to have. RNet always supports up to 32765 conferences _per_ RNETCONF configuration on your system! Host conference support by door (as of November 1990): KMail v1.xx Up to 32765 conferences available on the host system. MarkMail v1.xx ' 256 '' '' '' MarkMail v2.xx ' 32765 '' '' '' QMail v2.xx ' 128 '' '' '' QMail v3 & 4.xx ' 256 '' '' '' TomCat! v1.xx ' 256 '' '' '' RNET.DOC Page 8 ______________________________Echo Conferences_____________________________ Echo conferences are the same as any normal conference on your board except that the EchoFlag is used/supported. In PCBSM/PROSM, create a conference as normal. Then, under the field asking about "Echo mail in conference", specify YES. Beyond that single difference, an Echo conference is the same as any other (in setup that is). Be sure you specify enough "Index (NDX) blocks" to handle the inflow of network message traffic. If you pack your messagebases often (daily or perhaps weekly), you can probably get away with one or two blocks. If, on the other hand, you want to keep a large number of messages on-hand or if the traffic is extremely heavy (as with most debate conferences), you will more than likely want to use four or perhaps six blocks. Larger values waste space unless you intend to keep 10,000 messages in a given conference concurrently (or if you never pack the messagebases). Normally, messages entered in an Echo conference will not be echoed (send out over the network) without the EchoFlag turned on. When a user enters a message, they will be prompted "Echo this message?" If they specify YES, then the message will be echoed. If they specify No, then the message will remain on the local system only. Note that this can be overridden with the "IGNOREECHO=" keyword in the HOST_ID configuration file. ________________________________Commandline________________________________ RNet needs only simple information on the commandline to operate. Most of the information RNet needs is derived from the HOST_ID.CFG configuration file. You need only tell RNet what kind of operation you want it to do (such as IMPORT or EXPORT) and the HOST_ID. Commandline syntax: RNET Operation HOST_ID [Param1 Param2] Operation must be one of: EXPORT IMPORT SET TOP. HOST_ID is *required* for all operations. HOST_ID is specified for what configuration, QWK, and REP packet filenames to look for and should not contain an extension. You should contact your Host Sysop to find out what the HOST_ID is for your host's system. Examples of HOST_ID include FTL, TRP, EXECNET, CHEERS, HIGHER, and SEMWARE. Param1 and Param2 are used to specify additional information relating to the operation being executed. Param1, for example, is used to specify the conference to use for SET and TOP operations. See the text under each operation for specific usage. If you neglect to specify an operation RNet will display a help screen to remind you of the syntax. On this screen you will see the copyright notice, current version number, credits to Sysops who were helpful in implementing or testing that version, and the Alpha, beta, registered, or unregistered status. RNET.DOC Page 9 ___________________________________EXPORT__________________________________ Syntax: RNET EXPORT HOST_ID [ONLY LocalConf#] Export instructs RNet to scan your messagebases for new outgoing messages to be sent to your host. Any new messages found will be placed in a compressed HOST_ID.REP packet (appending or overwriting, depending on the instructions in the HOST_ID.CFG configuration). You would normally execute this operation before calling your host for mail. If needed, you may specify ONLY and a local conference number which will export new messages in the specified conference _only_. Examples: RNET EXPORT CHEERS ;Export new messages for host CHEERS! RNET EXPORT TRP ;Export new messages for host TRP RNET EXPORT TRP ONLY 5 ;Export only new messages in local conference 5 ___________________________________IMPORT__________________________________ Syntax: RNET IMPORT HOST_ID [ONLY|SKIPTO LocalConf#] Import is used to insert new messages from a QWK packet into your local messagebases. RNet will uncompress the HOST_ID.QWK packet(s), verify NetStatus, and import the messages it finds. You would normally execute this operation after having downloaded mail from the host. There are two optional Param1 specifications accepted for the import operation: ONLY and SKIPTO. If either of these are specified you must also specify a local conference number (Param2). ONLY allows you to import host messages in a specified conference. This is very useful for recovering from problems such as a disk full condition or similar disaster. SKIPTO allows you to import host messages in conferences beyond a specified local conference. This is very useful for continuing an aborted import. Simply look at the log to find the last imported conference then use that local conference number as Param2. RNet will then "pick up where it left off" and continue importing host messages. Examples: RNET IMPORT CHEERS ;Import messages from host CHEERS! RNET IMPORT TRP ;Import messages from host TRP RNET IMPORT TRP ONLY 5 ;Import messages destined for conference 5 RNET IMPORT TRP SKIPTO 5 ;Resume aborted import at conference 5 RNET.DOC Page 10 ____________________________________SET____________________________________ Syntax: RNET SET HOST_ID LocalConf# PointerValue RNET SET HOST_ID LocalConf# MessagesFromTop Though the host pointer file can be edited with a standard text editor (such as QEdit or Edlin), you may change a messagebase pointer with the commandline SET operation. Specify Param1 as the local conference number to change, Param2 as the value to change the pointer to. If Param2 is below the lowest numbered message, the lowest message will be used. If Param2 is above the highest message, the highest message number will be used. And finally, if Param2 is a negative value, RNet will use that value subtracted from the highest (top) message number. Examples: RNET SET FTL 10 99999 ;set conf 10 pointer to high message. RNET SET FTL 10 1 ;set conf 10 pointer to low message. RNET SET FTL 10 -100 ;set conf 10 pointer to 100 from the top. ____________________________________TOP____________________________________ This works very similarly to the SET operation but has the advantage of allowing you to change all the messagebase pointers at once. If Param1 is specified as a local conference number, RNet will reset that conference pointer to the high message in that messagebase. If Param1 is "ALL", RNet will reset all conference pointers to the high message in each messagebase. Examples: RNET TOP TRP 1 ;set conf 1 pointer to last (top) message. RNET TOP TRP ALL ;set ALL conf pointers to top. RNET.DOC Page 11 ___________________________Environment Variables___________________________ RNet will look for and make use of the following environment variables. Note that none of these environment variables are required, but are simply searched for and used if RNet cannot find what it needs elsewhere. RNET= Specify the D:\DIR\ where RNet should search for the HOST_ID.CFG file. RNet will first search the default (current) directory. To maintain some compatibility with the old QNet 1.xx system, RNet will look for the QWIKMAIL= environment if the RNET= environment is not found. Example: SET RNET=D:\PCB\RNET\ RNETCONF= Specify the complete D:\DIR\FILENAME that RNet should use for its needed conference information (about your board). If a filename is not specified, RNet will use the RNETCONF= value as a base drive/directory and search for RNETCONF there. By default, RNet looks for the file RNETCONF in the current directory. Use the RNETCONF= environment if you want RNet to look elsewhere and/or if you want it to use a different filename for RNETCONF. Example: SET RNETCONF=D:\PCB\RNET\ or SET RNETCONF=D:\PCB\RNET\RNETCONF.#2 TMP= Specify the D:\DIR\ where RNet should place working files (such as the uncompressed QWK and REP packets). The drive specified must have enough space to handle your largest packet. RNet will also look for the TEMP= and QWORKDIR= environment variables, in that order. Note that the HOST_ID configuration keyword WORKDIR= takes priority over the environment. If you wish to have RNet use one of these environment variables, neglect to put WORKDIR= in the HOST_ID.CFG file. Example: SET TMP=Z:\SCRATCH99\ NODE= The NODE= environment is used to tell RNet what node number it is running on so that it can correctly update NODE CHAT and CALLERS log. The value must be from 0 to 99. If NODE= is specified in the HOST_ID.CFG, it takes precedence over the NODE= environment. Example: SET NODE=1 RNET.DOC Page 12 ____________________________Configuration Files____________________________ For every host you will be echoing from you will need to create a configuration [CFG] file. You may create additional configuration files and "switch them in and out" based on needs. A CFG file is a simple ASCII text file listing keywords and information. RNet will parse the HOST_ID.CFG file (HOST_ID being what was given on the commandline that specifies the net name of your host system) to get the information it needs. RNet will first check the default directory, then look for a RNET= environment variable (specifying a drive:\directory path) to try to find the HOST_ID.CFG file. If it fails to find the CFG file, RNet will abort operation reporting "Configuration file not found!" Configuration files can and should be created with a standard text editor such as QEdit or even Edlin. Blank lines and lines beginning with a semi-colon (";") will be ignored. Each keyword should be specified on a separate line and should have no trailing spaces between the keyword itself and an equals ("=") sign that should follow. Please see the example CFG files included in this ZIP file for a template to use. In a future version a Configuration program will be included to ease the configuration process. Meanwhile, it is recommended that you use an existing template (example) CFG file to work with -- simply use the DOS COPY command to copy/rename a SAMPLE?.CFG to the needed HOST_ID.CFG configuration file. Most keywords have synonym words (SYN) listed in the description. These alternate keywords have the same meaning as the base keyword and may be used interchangably. The minimum keywords needed for any configuration file: HOSTSYSOP (the host sysop name) SYSOP (your name) HOSTORIGIN (host system tagline) [or HTAG0] ORIGIN (your system tagline) [or TAG0] CONF (one per conference being echoed) [or CONVERT] Highly recommended to be included in any configuration file: REPLYPROCESS (so you know exactly what to expect) WORKDIR (or allow environment to specify) NODE (or allow environment to specify) USERNET (even if only specifying "NONE") You might do well using the example HOST_ID.CFG file as a base for creating your configuration files. Simply copy or rename the HOST_ID.CFG file to the proper name for your host (replace HOST_ID with the node/netname of the host maildoor, such as FTL or TRP, or EXECNET), then edit the file as needed. Remove any excess CONF statements to avoid exporting messages into the wrong conferences! RNET.DOC Page 13 _________________________Keywords: Names and Users_________________________ HOSTSYSOP Actual name of your host sysop. This is the name that incoming messages addressed to/from "SYSOP" on your host systems board will be translated into. SYN: HOST_SYSOP SYSOP Your name. Messages addressed to/from "SYSOP" on your system will be translated into this name for outgoing messages. SYN: LOCAL_SYSOP LOCALSYSOP MAKESYSOP YES|NO; Should RNet address incoming mail to "SYSOP"? If you specify YES to this keyword, RNet will translate any incoming messages addressed to/from your name into "SYSOP." SYN: MAKE_SYSOP PRIVATEUSER Up to 25 users may be specified as "private mail users". Any users specified by a PRIVATEUSER= entry in the CFG file will be allowed to send private (R/O) messages despite the global PRIVATE= setting. Useful for moderators, hosts, net sysops, and administration folks to send private messages up the network. Note that this does not change the settings of your host's mail door -- private messages sent from the host are controlled by the host. SYN: PRIVATE_USER SPECIAL_USER PRIVATE_MAIL SPECIALUSER Example: PRIVATEUSER=GEORGE CARLIN TCAN You may specify up to 25 names (one full name per line) which RNet should refuse to process. Any message addressed to/from this user will not be imported or exported but instead written to TCAN.LOG in the current directory. SYN: TRASHCAN TRASH BADUSER BAD_USER TOCAN You may specify up to 10 names with the TOCAN keyword (one name per occurrence of TOCAN in the CFG file). If a message is addressed TO this name, RNet will refuse to import/export it. As with TCAN, the refused messages are written to TCAN.LOG for your review. SYN: TRASHCAN_TO TO_TCAN FRCAN The same as TOCAN except checks the name against the FROM field for each message instead of the TO field. SYN: TRANSHCAN_FROM FROMTCAN FROM_TCAN RNET.DOC Page 14 HANDLE Up to 25 handle/alias translations may be specified. This keyword allows translation of the user name in the TO/FROM fields in two ways. Because there are two forms for this keyword it has confused folks in the past. Hopefully, these explanations and examples will help. Format: HANDLE=AlwaysFromThis,AlwaysToThis Example: HANDLE=SPARKY,MARK HERRING This example will translate "SPARKY" to "MARK HERRING". *Everytime* "SPARKY" is seen in the to/from fields of a message it will be changed into "MARK HERRING". The name "SPARKY" will basically never appear locally or on the network, as it will *always* be changed to "MARK HERRING". During the name is changed to --------- ------------- ------------- IMPORT SPARKY MARK HERRING IMPORT MARK HERRING MARK HERRING EXPORT SPARKY MARK HERRING EXPORT MARK HERRING MARK HERRING The second method of name translation allows you to change a name one way during import and the other during export. Thus, you can specify how a name appears on your board which is different from the way it appears over the network. Note the addition of the asterisk in the following example: Format: HANDLE=*ExportAsThis,ImportAsThis Example: HANDLE=*SPARKY,MARK HERRING The asterisk is used to signify that you wish the translation to "reverse" when doing an export. Anytime the name "SPARKY" or "MARK HERRING" is seen during an import, it is changed into "MARK HERRING". Anytime "SPARKY" or "MARK HERRING" is seen during an export it is instead changed into "SPARKY". During the name is changed to --------- ------------- ------------- IMPORT SPARKY MARK HERRING IMPORT MARK HERRING MARK HERRING EXPORT SPARKY SPARKY EXPORT MARK HERRING SPARKY Thus the name "SPARKY" will always appear over the network while the name "MARK HERRING" will always appear on your board. Use HANDLE=Name1,Name2 when you *always* want 'Name1' to be changed into 'Name2'. Use HANDLE=*Name1,Name2 when you want 'Name1' to appear on the network and 'Name2' to appear on your board. SYN: ALIAS NAME_CHANGE RNET.DOC Page 15 _____________________________Keywords: Taglines____________________________ Taglines are always forced into a standard format. Before the first tagline that is to appear on a message, a tearline must appear. A tearline is composed of a line with three dashes ("---") optionally followed by additional text (FidoNet compatable method). All taglines follow this tearline and begin with either " ■ " or " * ". RNet will automatically fix taglines from other software packages that do not conform to this standard and will remove blank lines from between taglines. RNet will automatically chop off any taglines in excess of two. HOSTORIGIN Use HOSTORIGIN to specify what tagline to place on messages that originate from your HOST system. The host's mail door does not place any taglines on messages, it is up to your end of things. The tagline should conform to whatever network standards are currently in effect. Note that the synonym HTAG0 is commonly used instead of HOSTORIGIN. SYN: HTAG0 HOST_ORIGIN HOST_TAG HOST_TAGLINE HOSTTAG Example: HOSTORIGIN= ■ Host board name ■ City ■ Phone Number HTAG0..9 The ten HTAGx statements allow you to specify up to ten different host taglines. HTAG0 is the same as HOSTORIGIN and may be used in place of it. To specify which of these ten taglines is to be used as the host tagline on any given conference, see the CONF statement below. ORIGIN ORIGIN is used to specify the tagline to be placed on messages coming from your system. All messages exported from your system that originated from your system will have this tagline placed on them. The tagline should conform to the network standards of the network in question. SYN: TAG0 TAGLINE LOCALTAG LOCAL_TAG Example: ORIGIN= * BBS Name, City, Phone Number TAG0..9 The ten TAGx keywords allow you to specify up to ten different taglines for messages originating from your system. TAG0 is a replacement for ORIGIN and can be used in place of it. To specify which of these ten taglines are to be used for each specific conference, see the CONF statement. FORCETAG YES|NO. If you specify YES for this keyword, RNet will *always* append a tagline (host or origin, as appropriate) on all messages processed. Note that if the tagline addition causes more than two taglines to be appended to the message, any in excess of two will be stripped. This is used mostly for forcing tagging of messages for debugging use. SYN: FORCE_TAG FORCE Default: NO (disabled; add tagline only when/if needed) RNET.DOC Page 16 FORCENOTAG YES|NO. Specify YES to this keyword if you want to force RNet *not* to append any taglines to any messages processed. In smaller and in-company business echo networks, you might desire to have no taglines. SYN: NOTAG FORCE_NO_TAG Default: NO (disabled; add tagline if needed) RTAG YES|NO|ORIGIN. The RTAG keyword enables (YES) or disables (NO) the " ■ RNet v.vvx: " on the beginning of each tagline. If RTAG=ORIGIN is specified, RNet will use the Fido standard " * ORIGIN: " at the beginning of the line and append ":RNet v.vvx" to the end. Note that this keyword is subject to different effects depending on the version/release of RNet: Alpha/Beta: specifying NO changes the tagline id to a shorter id (" ■ Rvvvx:"). This information is used for debugging (watching) RNet operate over several large networks where strict control is not possible. Unregistered: RTAG=YES and RTAG=NO have no effect. Registered: specifying RTAG=NO will completely remove the " ■ RNet" part of the tagline. In this case, the text you specify for host/origin (HTAGx and TAGx) taglines will be the *complete* text used for the taglines. SYN: RNETTAG RNET_TAG R_TAG FIXJH YES|NO. This keyword tells RNet if it should automatically decrypt encrypted John Hancock version 2.xx taglines. Some networks do not allow encrypted taglines so this option allows you to decrypt them automatically. If you specify FIXJH=YES, both incoming and outgoing messages will be checked and decrypted. SYN: FIX_JH_TAGS Default: NO (leave encrypted JH taglines alone) ________________________Keywords: Packet Processing________________________ COMPRESS Specify the program and options needed to compress a REP packet for sending to your host. Check with your host about what program/method should be used for packet compression (most commonly PKZIP). All appropriate filenames will be added to this command when RNet calls it, so only specify the command and switches (if any) needed. NOTE: If the program needed is not in the current directory or along the DOS PATH= environment, specify the complete d:\dir\filename.ext. SYN: PKPAK ARC PAK PKZIP ZIP Default: PKZIP -m -ex RNET.DOC Page 17 UNCOMPRESS Specify the command (program) needed to uncompress an incoming QWK packet from your host. Check with your host as to what program is needed. The command must accept placing of a directory specification on the end (last parameter) for RNet to place the files in the work directory. If this does not work correctly (ie, is not supported by the decompression program), you will need to remove all references (CFG and environment) to WORKDIR= so RNet uses the current directory. SYN: PKUNPAK UNARC UNPAK PKUNZIP UNZIP Default: PKUNZIP -o WORKDIR Use WORKDIR to specify the drive/directory where RNet should place scratch files and uncompressed QWK packets. If you have a large enough RAM drive, specify that. When RNet is done processing, it will only delete the files it created or uncompressed, thus, you may even use the current directory safely if desired. Note that the drive/directory pointed to by WORKDIR must already exist or RNet will report an error. A recommended drive/directory would be the "play" or "scratch" directory used by the processing node for up/download processing. This setting (WORKDIR) overrides the TMP= environment. REPLYPROCESS APPEND|OVERWRITE. Specify APPEND for this keyword if you want RNet to append new outgoing messages to an existing REP packet. This allows you to keep adding to the end of a REP packet when your host has been busy. *WARNING*: if you use this option, you must delete your HOST_ID.REP packet after successful upload to your host. Failure to do so will result in uploading duplicate messages! SYN: REPLY_PROCESS Default: Delete (overwrite) existing HOST_ID.REP packets. ARCHIVE The only option for this keyword is EXTERNAL and should only be specified if you are prepared to handle it. If you specify ARCHIVE=EXTERNAL, RNet will not shell to DOS to execute the COMPRESS and UNCOMPRESS commands, but will instead assume that you are going to handle these functions before and after calling RNet. If you are in a tight memory situation, you will likely need to use this option. Please see LOWMEM.BAT for more information and an example of how to handle compression/decompression in this manner. QWKPATH Specify the d:\dir\ where RNet should look for QWK packets from your host. RNet will automatically process multiple packets (HOST_ID.QW?) if found, in numerical order. You should use this keyword to point to the download d:\dir\ that your terminal communications program downloads QWK packets to. SYN: QWK QWKS QWK_PATH QWKPACKETS QWK_PACKETS Default: Current drive/directory RNET.DOC Page 18 REPPATH Use this keyword to specify the d:\dir\ where RNet should create HOST_ID.REP packets for sending to your host. Usually this will be the d:\dir\ where your terminal program expects to find files for uploading. SYN: REPLOC REP_PATH REPDIR REP_DIR Default: Current drive/directory KILLQWK YES|NO. The KILLQWK keyword allows you to instruct RNet to delete the HOST_ID.QWK packets after *successful* import. If anything goes wrong or if RNet has reported any warnings, the packet will not be deleted. This can be useful for your event batch file to figure out if the import process proceeded without any problems simply by looking for the existence of *.QW? after import processing. If *.QW? exists, something went wrong. If you do not use this option, be sure to manually delete or move the packet before your next mailrun to avoid inserting duplicate messages. SYN: KILL_QWK DELETEQWK DELETE_QWK Default: NO (QWK packets are not automatically deleted) CHECKREP YES|NO. If you wish, RNet can check for, and prompt you for what to do with an existing REP packet (during both IMPORT and EXPORT setup operations) when it finds one. Specify CHECKREP=YES to have RNet look for any existing REP packets, and if one exists, prompt you to: Delete the packet and continue; Retain the packet and abort operation; Continue normally (default). RNet will wait for 10 seconds for you to make a decision. This option is available so that if you do manual processing of a mailrun, you will be prompted about the disposition of any existing REP packets that you may have forgotten to manually delete. SYN: CHECK_REP Default: NO (do not prompt operator for REP disposition) CKPOINTERS YES|NO. By default, RNet will automatically check all its current pointers against the existing messagebases (which can take a minute or two if you have 2000+ echo conferences). If it finds a problem, it will automatically correct the pointer file. Pointers are checked against the current High and Low message numbers in the conference messagebase to determine that the pointer is valid. You may specify CKPOINTERS=NO to disable this safety feature (this is *not* recommended!). SYN: CHECKPOINTERS CHECK_POINTERS Default: YES (check all pointers every time RNet is run) RNET.DOC Page 19 _________________________Keywords: Message Handling________________________ PRIVATE YES|NO. This is a global specification as to if private (R/O) messages are allowed on the network in question. If the network you are connecting to allows *all* users in *all* conferences to send private (R/O) messages, specify PRIVATE=YES. Note that RNet will honor the PCBoard/ProDoor conference configuration (PCBSETUP/PROSM) which specifies that all messages should be private (R/O) regardless of this keyword setting. Use PRIVATE=NO and PRIVATECONF (see below) to specify private messages are allowed only in specific conferences. SYN: SENDPRIVATE SEND_PRIVATE Default: NO (send only public messages) COMMENTS YES|NO. This keyword specifies if Sysop COMMENT security messages should be exported. This is useful if you are running multiple BBS's and want to send all messages from one system to another via RNet. Note that PRIVATE must be specified YES as well for this option to be in effect. SYN: SENDCOMMENTS SEND_COMMENTS Default: NO (do not send COMMENT security messages) PRIVATECONF You may specify a list of local conference numbers (separated by commas) in which private messages are permitted to be transmitted. This option is added such that you may have a network which only allows private (R/O) messages in certain conferences. You may specify as many PRIVATECONF statements as needed or desired. Note that using PRIVATE=YES is the global of this keyword. SYN: PRIVATE_CONF Example: PRIVATECONF=1,10,11,12,200,201 IGNOREECHO As with PRIVATECONF, you may specify a list of conferences (ie, by local conference number) in which you want to ignore the PCBoard 14.x EchoFlag status. This is useful if you have an automated process or another mail package that turns off the EchoFlag for some reason and you want to export the messages despite the EchoFlag. Normally, RNet will not export messages that do not have the EchoFlag specifically enabled on them. SYN: IGNORE_ECHO Example: IGNOREECHO=5,6,7,10,11,12,200,201 ANSICONF This keyword is used to enable ANSI escape sequences in any given conference(s). List conferences by local conference number (as with IGNOREECHO above). RNet will "fix" translated (filtered) ANSI sequences when it can in these conferences. SYN: ANSI ACCEPT_ANSI RNET.DOC Page 20 KEYCODE KEYCODE is used to support multiple or cross echoed networks within the same conferences. KEYCODE specifies a single character, preferably one of !, @, #, $, %, ^, &, or a single alphanumeric character, which is to be used to specify the network of origin of a message. If you are only echoing a single network or if you are not involved in cross echoing of multiple networks into the same conferences (ie, not a 'gateway'), simply specify KEYCODE=! or something similar (DO NOT USE "*") and ignore the rest of this description. Specify a different KEYCODE for each network you will be echoing. For example, if echoing ILink, you might specify KEYCODE=I, and for CanConfMail, specify KEYCODE=C. Doing this, if you echo both networks into the same physical conference, messages from either network will be sent out to the other automatically (along with all replies and messages coming from "lower" on the networks). This is known as a 'Gateway' connection. If you wish to import multiple networks into the same conference and do not want to send the messages from one network to the other, specify the same KEYCODE for both networks (such as KEYCODE=! for in both configurations). In this case (both KEYCODEs being the same), messages from one network host will *not* be sent to the other while all messages originating from your board (or lower on the network(s)) *will* be exported to both network hosts. Not likely desired or needed, but the ability is there. Basic logic description: All messages imported will have the defined KEYCODE assigned to them. During export processing, any messages that have the exact KEYCODE on them will not be exported (thus avoiding bouncing messages back up the net). Messages sent up to your board from lower on the network will always have a keycode of "*". If you did not want to send messages from lower on the network up the network (who knows why you would want to do this?!), specify a KEYCODE of "*". SYN: BBSKEY BBS_KEY BBS_KEYCODE Example: KEYCODE=! ___________________________Keywords: Conferences___________________________ CONF You must specify one CONF statement for every echo conference you are intending to echo with your host. The CONF keyword is used to specify how your local conference numbers correspond to the host's conference numbers. You may also use it to specify an alternate tagline to be used for each conference (see HTAG0..9 and TAG0..9 above). Commonly, the synonym CONVERT is used for CONF. Format: CONF=Local#,Host#:Tag# Note that the ":Tag#" part of the CONF statement is optional RNET.DOC Page 21 and only needed if you wish to specify using taglines other than HTAG0 and TAG0 (see HTAG0..9 above). You may place "comments" after the CONF statement (avoid using a ":" in the comment!) such as listing the conference name. The examples below are valid as they are. See also the SAMPLE?.CFG files. SYN: CONVERT CONFERENCE Example: CONF=1,55 (my 1 = host 55, use H/TAG0 tags) Example: CONF=2,56:0 (my 2 = host 56, use H/TAG0 tags) Example: CONF=3,60:1 (my 3 = host 60, use H/TAG1 tags) Example: CONF=4,61:1 (my 4 = host 61, use H/TAG1 tags) Example: CONF=5,62:1 (Sysops Echo) _____________________________Keywords: NetNews_____________________________ NetNews keywords are used to allow a network to support a special "NetNews" type conference that has only special news messages from the network administration. The philosophy behind the RNet NetNews conference support is to create a conference that is not echoed, but instead has messages inserted in it that come from another conference. The messages inserted into this special NetNews conference are designated by key words and users as defined by the following keywords. Ask your network administration if this form of NetNews conference support is available and/or simply monitor the administration conferences and figure out for yourself what "special" messages should be extracted into a special conference (presumably, public for all users to read). All messages imported/exported in the NETADMIN conference are checked. Any message that is addressed to ALL, addressed from NETADMIN, and the subject contains the text specified by NETSUBJECT, will be copied to the NETNEWS conference as public and non-echo. NETNEWS Specify the local conference (by number) to be used as the destination for NetNews type messages. Messages which match the parameters specified by the other keywords will be copied into this conference. This will commonly NOT be an echo conference and usually has the "Make all messages private" option turned on in PCBSM/PROSM. RNet will insert messages here as public (despite the "Make private" setting). SYN: NET_NEWS NET_NEWS_CONF Example: NETNEWS=15 (use local conference 15 for NetNews) NETADMIN Specify a local conference number that is normally used for Administration level messages. This conference will be checked during processing for messages that match NETADMINID and NETSUBJECT. Messages which match the requirements will be copied to the NETNEWS conference. The original messages will still be imported/exported in this conference so that it is passed to other systems up and down the network. SYN: NET_ADMIN NET_ADMIN_CONF Example: NETADMIN=44 (search conf 44 for NetNews messages) RNET.DOC Page 22 NETADMINID Use this keyword to specify the name that a message must be FROM to qualify as a NetNews message. Usually this is either a special alias (such as "Network Administration") or someone in the administration. The message in question must also be addressed to "ALL" to qualify -- this keeps replies and other comments from appearing in the NetNews conference. SYN: NET_ADMIN_ID NETADMIN_NAME NET_ADMIN_NAME Example: NETADMINID=NETWORK ADMINISTRATION NETSUBJECT Messages in the NETADMIN conference are checked, and assuming the message matches the NETADMINID the NETSUBJECT is checked. Specify a key phrase or word that must appear in the subject of the message to qualify as a NetNews message. Usually this is something along the lines of "** ANNOUNCEMENT **". The subject need not match exactly, but must contain the phrase or words specified with this keyword (which is *not* case sensitive). SYN: NET_SUBJECT Example: NETSUBJECT=** ANNOUNCEMENT ** Logic example: Using the examples above, if a message appears in local conference 44 (either during import or export processing, so it works even when the message is going "up" the network) is addressed to "ALL", is from "NETWORK ADMINISTRATION" and has the text "** ANNOUNCEMENT **", that message will be copied to local conference 14 as public and non-echo. ________________________Keywords: Multinode/NodeChat_______________________ If you are running a multinode system concurrently with your RNet event processing (which is perfectly safe by the way), you should specify the following keywords to help RNet determine how to proceed. RNet honors and will check the PCBoard messagebase LOCKED field when inserting messages in all cases. Assuming you specify these keywords correctly, you may "watch" RNet processing via the NODE CHAT display. NODE This keyword, when used, will override the environment variable NODE. If you specify a value of 1-99, RNet will "login" to that node as far as the Node Chat and CALLERS logs' are concerned (see CALLERLOG below). Specify a value of 0 and USERNET=NONE if running a single node system. Specify a value of 0 and correctly specify USERNET=d:\dir\usernet.dat to have RNet use the NODE= environment. SYN: PCB_NODE NODE_NUMBER PCBNODE NODENUMBER Example: NODE=3 (mail events are processed by node 3) USERNET Specify the d:\dir\filename.ext of the PCBoard node chat USERNET.DAT file. RNet will show up as a node on the Node Chat display reporting exactly what it is doing (Init, Exporting xxx, Importing xxx, Cleanup, etc) via the city/state field. RNet must have this keyword specified correctly for its automatic speed selection from fast/slow. If RNet sees a user on another node who is: Unavailable, Entering a message, or Out of code in door, then RNet will use a slow (safer) RNET.DOC Page 23 concurrent message entry routine. If all users are Available or doing other things, RNet will use a faster insertion routine (it will not flush the directory structure between each message). If running a single node system specify USERNET=NONE. SYN: NETUSER NETUSERS NETDATA NETINFO Example: USERNET=D:\PCB\MAIN\USERNET.DAT _____________________________Keywords: Reports_____________________________ CONFREPORT Specify the complete d:\dir\filename.ext that RNet should write the conference analysis report to. This report shows each configured conference, number of messages exported/ imported, locally created, percentages comparisons to traffic locally and netwide. Very handy report to keep around! SYN: CONF_REPORT REPORTFILE REPORT_FILE Example: CONFREPORT=D:\PCB\GEN\BLT20 SUPERLOG If you want this report, specify a d:\dir\filename.ext for this keyword. The SUPERLOG (aka ALLMESSAGELOG), is a listing of every message imported or exported by conference, message number, subject, date, addressed to and from. This log can quickly eat up valuable disk space (similar to the way a CALLERS log can), so don't let it sit around without attention too long. SYN: ALLMESSAGELOG Example: SUPERLOG=D:\PCB\GEN\ALLMSGS.LOG DAILY YES|NO. Enable or disable the daily report analysis logging. RNet will normally create a log report listing each conference and the number of imported/exported messages. These reports are automatically maintained for the last six days based on the day of the week. The files created are in the default directory named VERBOSE.XXX where XXX is the day of the week (such as SUN, MON, TUE). RNet always deletes "tomorrow's" report so that the reports do not consume excess drive space. Specify NO if you want to disable this reporting function. SYN: DAILYLOG DAILY_LOG CALLERLOG If you want RNet to report the number of messages imported and exported in each conference to the CALLERS log, use CALLERLOG to specify the d:\dir\filename.ext for your CALLERS log file. If you are running a multinode system, do NOT include the node number on the end of the file as RNet will automatically append this. If running a single node system (ie, NODE=0), RNet will not append a node number to the filename. RNet will report itself logging in, a baud rate of (Event), Graphics on, and IMPORT or EXPORT for the city/state field. Next, it will list each conference that has at least one message of traffic in it and the total number of messages imported or exported. Finally, RNet will report the number of minutes used and logoff "normally" (if that is the case). SYN: CALLER_LOG CALLERS RNET.DOC Page 24 Example: CALLERLOG=D:\PCB\MAIN\CALLERS LONGCALLER YES|NO. If you specify YES for this keyword, the CALLERLOG report will be much more verbose. The LONGCALLER report lists every message imported/exported as if a "user" had left the messages in the first place. This can be useful for caller analysis programs to know exactly how much message traffic is occuring in each conference. SYN: VERBOSECALLERLOG VERBOSE_CALLER_LOG LONG_CALLER_LOG Default: NO (use the short callerlog report format) ____________________________Keywords: Additional___________________________ EXTENDED YES|NO. This keyword is used to clarify to RNet if your host is using or supporting more than 255 conferences. This may or may not be needed depending on the mail door you are using on your host. If you are using MarkMail 2.xx or KMail with conferences numbered higher than 255 on your host (your local conference numbers are not important), you may need to specify EXTENDED=YES to be sure RNet understands. RNet should be able to determine this for itself, but since as of the time of this release no mail door supports this yet, it is difficult to test. SYN: EXTENDED_CONFS EXTENDEDCONFS RUN You may specify as many RUN statements in your configuration file as desired. When RNet encounters the RUN keyword in the configuration file, it takes the text following the equals sign and executes a DOS COMMAND.COM/C shell with the command specified. This is useful if you want to be sure RNet does something every time it is run without having to remember to run a batch file to access RNet. A common use is to force RNEt to update its RNETCONF file with any changes to your conference setup since the last time it ran. Example: RUN=PCBCONF d:\pcb\main\cnames -i Example: RUN=IF EXIST *.QW? COPY *.QW? D:\HOLDQWKS RNET.DOC Page 25 ____________________________Initial Installation___________________________ [This assumes that you have already arranged NetStatus with your host BBS and is the most common setup design folks use for RNet. Additional steps (such as step 5) are added to account for differing situations.] 1. Create a directory for RNet. Copy all the files from the distribution ZIP into this directory. Later, you can delete any files you don't need or want (such as the SAMPLE?.CFG files). 2. Run either PCBCONF.EXE or PROCONF.EXE to create the RNETCONF file -- RNet will not operate without this file being created. If running PCBoard 14.x, use PCBCONF. If running ProDoor 2.9+, use PROCONF. Syntax: PCBCONF D:\DIR\CNAMES Syntax: PROCONF D:\DIR\CONFINFO 3. Use a text editor such as QEdit or Edlin to create a HOST_ID.CFG file. If desired, use one of the SAMPLE?.CFG files as a starting point by renaming or copying it to the appropriate HOST_ID.CFG name. Example: FTL.CFG (Faster-Than-Light BBS as host) Example: TRP.CFG (The Right Place<tm> BBS as host) Example: EXECNET.CFG (Executive Network BBS as host) See the documentation above for more information on HOST_ID.CFG files. 4. Run RNet to create a pointer file. RNet will automatically check the pointers against the messagebases after the pointer file is created. The TOP operation is selected in case you have another utility you have been using for echomail so that messages will not be lost (see step 5). Syntax: RNET TOP HOST_ID 5. If you were previously running another echomail utility, run it one last time to export any messages which need to be exported. This is done _after_ step 4 so that any messages entered on another node between steps 4 and 5 will not be lost. If you were previously running QNet or another QWK packet echomail package, place the newly created REP (if there is one) where you have instructed RNet to look for/create REPs. Commonly, this is either the RNet directory or the directory where your terminal program expects to find files for uploading. Assuming you have RNet set to APPEND to REPs (default configuration), RNet will append any new outgoing messages to this REP the next time you run an EXPORT. If you were previously running a non-QWK compatible echomail package, you should upload/send/do-whatever-is-needed the file up to your host -- it might be convenient to do this while handling step 6. 6. Call the host system and configure the mail door. Open the mail door you will be using for your echomail transfers. Configure the mail door for the conferences you will be transferring -- set all pointers as appropriate, usually by "topping" all conferences. RNET.DOC Page 26 If you were previously using a QWK packet system, you probably need change nothing. If you have a REP file for upload, you should upload it now. 7. Download a QWK packet. You might want to change the pointers on all of the conferences you will be echoing such that you get SOMETHING in every conference. In other words, set the pointer for each conference to one less than the high message number. This should result in you getting one message per conference. Download the QWK to the directory where you have told RNet to expect to find QWK's. 8. Logoff the host, go back to the RNet directory and execute a RNET IMPORT HOST_ID -- this assumes that you did get a QWK packet while in the mail door. Watch the operation to be sure that nothing is wrong (conferences go where they should, work directory exists, etc). Make any changes to the HOST_ID.CFG as needed. After successful IMPORT of the QWK packet, be sure to delete it (if you have KILLQWK=NO). 9. Setup an automated method (suggested) of transferring the mail. Usually this is done via EVENT.SYS and a communications program script or perhaps a package such as RoboComm. 10. If you have any questions or problems, you host will probably have the quickest answers and can help. If RNet refuses to run or has a problem, it will report (both to the screen and to an ERROR.LOG file) where it is having difficulties. Check drive & directory entries carefully, as they are the most common problem causing elements. RNET.DOC Page 27 _________________________Copyrights and Trademarks_________________________ All programs mentioned are copyrighted and/or trademarked by their respective holders. Please refer to each respective program to determine the actual copyright/trademark holder as appropriate or needed. ______________________________Acknowledgments______________________________ Roger Sligar -- Sysop of The Right Place<tm> in Atlanta. He gets top billing around here for all his support/prodding/effort and uncountable hours of chasing down bugs/messages across the world! It was the desire to safely and dependably run a couple echo's with TRP that was the invention of RNet. Mark Herring -- Inventor of the QWK format and offline readers/maildoors. Without his original ideas to bring offline readers to the PCBoard market, RNet would never have existed. ILink -- (formally InterLink). A good international network of good folks who very quickly adopted RNet into wide use. It is for the continued growth of networks like ILink that RNet is constantly being improved. ... and all the registered Sysops who are running RNet! -- Thank you for your support and as always, please let me know of any ideas or suggestions you have! I hope you and your users enjoy the wild and wonderful world of EchoConferences!